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Abstract. By capturing common structures of successful arguments, safety case 
patterns provide an approach for reusing strategies for reasoning about safety. In 
the current state of the practice, patterns exist as descriptive specifications with 
informal semantics, which not only offer little opportunity for more sophisticated 
usage such as automated instantiation, composition and manipulation, but also 
impede standardization efforts and tool interoperability. To address these con- 
cerns, this paper gives (i) a formal definition for safety case patterns, clarifying 
both restrictions on the usage of multiplicity and well-founded recursion in struc- 
tural abstraction, (ii) formal semantics to patterns, and (iii) a generic data model 
and algorithm for pattern instantiation. We illustrate our contributions by appli- 
cation to a new pattern, the requirements breakdown pattern, which builds upon 
our previous work. 

Keywords: Safety cases, Safety case patterns, Formal methods. Automation. 


1 Introduction 

Safety case patterns are intended to capture repeatedly used structures of successful 
(i.e., correct, comprehensive and convincing) arguments, within a safety case [1 1]. In 
effect, they provide a re-usable approach to safety argumentation by serving as a means 
to capture expertise, so-called tricks of the trade, i.e., known best practices, successful 
certification approaches, and solutions that have evolved over time. The existing notion 
of a pattern 1 is an extended argument structure, often specified graphically using the 
Goal Structuring Notation (GSN) [8], which abstractly captures the reasoning linking 
certain (types of) claims to the available (types of) evidence, and is accompanied by a 
clear prescription and proscription of its usage. 

In current practice, patterns have informal semantics and, in general, they are given as 
descriptive non-executable specifications. Specifically, in existing tools, pattern-based 
reuse does not go beyond simple replication of a pattern argument structure, and man- 
ual replacement of its abstract elements with their concrete instances. Such usage is 
not only effort intensive but also unlikely to scale well. Algorithmically instantiating 
patterns is a natural solution to address this deficiency. However, to our knowledge, 
existing tools provide little to no such functionality, in part, because of the lack of a 
formal basis. The latter additionally impedes standardization and tool interoperability. 

1 In the rest of the paper we will simply use “pattern” instead of “safety case pattern”. 
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This paper extends the state of the art in safety case research though the follow- 
ing contributions: we give a formalization for argument structures elaborating on the 
nuances and ambiguities that arise when using the available GSN abstractions [8] for 
pattern specification. In particular, we clarify restrictions on the usage of multiplicity 
and extend the basic concepts to include a notion of well-founded recursion. Next, we 
give a formal semantics to patterns in terms of their (set of) concrete instantiations. We 
specify a generic data model and pattern instantiation algorithm, and illustrate their ap- 
plication to a new pattern: the requirements breakdown pattern, which builds upon our 
previous work [3], [6]. Specifically, both generalize and replace their previous incarna- 
tions [3] that mainly operated on requirements and hazard tables. 

2 Background 

Currently [10], [1 1], a pattern specification mainly contains: 

- Name : the identifying label of the pattern giving the key principle of its argument. 

- Intent: that which the pattern is trying to achieve. 

- Motivation: the reasons that gave rise to the pattern. 

- Structure: the abstract structure of the argument given graphically in GSN. 

- Participants: each element in the pattern and its description. 

- Collaborations: how the interactions of the pattern elements achieve the desired 
effect of the pattern. 

- Applicability: the circumstances under which the pattern could be applied, i.e., the 
necessary context. 

- Consequences: that which remains to be completed after pattern application. 

- Implementation: how the pattern should be applied. 

In addition, previously known usages, examples of pattern application, and related pat- 
terns are also given to assist in properly deploying a particular pattern. A variety of such 
pattern specifications can be found in [1], [10], and [15]. 

We assume that the reader is familiar with the basic syntax of GSN and do not repeat 
it here. The GSN standard [8] provides two types of abstractions for pattern specifica- 
tion: structural and entity. 

Structural abstraction, which applies to the is-solved-by and the in-context-of GSN 
relations, is supported by the concepts of multiplicity and optionality. The former gene- 
ralizes n-ary relations between GSN elements, while the latter captures alternatives in 
the relations, to represent a k-oi-m choice, where k > 1. There are, further, two types 
of multiplicity: optional , implying zero or one, and many, implying zero or more. Mul- 
tiplicity can be combined with optionality: placing a multiplicity symbol prior to the 
option describes a multiplicity over all the options. This is equivalent to placing that 
multiplicity symbol on all the alternatives after the option [8]. 

For entity abstraction, GSN provides the notions “Uninstantiated (UI)”, and 
“Uninstantiated and Undeveloped (UU)”. The former refers to abstract elements whose 
parameters are replaced with concrete values upon instantiation. The latter refers to UI 
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entities that are also undeveloped 2 . Thus, upon instantiation, an abstract UU entity is 
replaced with a concrete, but undeveloped, instance. 

In addition to these, there are (limited) examples of the use of a recursion abstraction 
in the literature [12], although it is not formally part of the GSN standard. Recursion, 
in the context of patterns, expresses the notion that a pattern (or a part of it) can itself 
be repeated and unrolled, e.g., as part of an optional relation or a larger pattern. Recur- 
sion abstractions may or may not be labeled with an expression giving the number of 
iterations to be applied in a concrete instance. 

3 Formalization 

In this section, first we modify an earlier definition of a partial safety case argument 
structure [3], [7], adding a labeling function for node contents. Then, we give a for- 
mal definition of a pattern, clarifying conditions on multiplicity and recursion. Subse- 
quently, we give a formal semantics to patterns as the set of their concrete instances, via 
a notion of pattern refinement. 

Definition 1 (Partial Safety Case Argument Structure). Let {s, g, e, a,j, c} be the 

node types strategy, goal, evidence, assumption, justification, and context respectively. 
A partial safety case argument structure S is a tuple ( N , l, t , -a), comprising the set 
of nodes, N, the labeling functions l : N -A {s, g, e, a, j, c} that gives the node type, 
t : N -A E giving the node contents, where E is a set of expressions, and the connector 
relation, -A: (N, N), which is defined on nodes. We define the transitive closure, — >*: 
{N, N), in the usual way. We require the connector relation to form a finite directed 
acyclic graph (DAG) with the operation isrootN{t ) checking if the node r is a root in 
the DAG 3 . Furthermore, the following structural conditions must be met: 

( 1 ) Each root of the partial safety case is a goal: isroot^(r) => l (r) = g 

(2) Connectors only leave strategies or goals: n -A m =>• l(n ) £ { s, g} 

(3) Goals cannot connect to other goals: (n — > m) A [l(n) = g\ =>• l(m ) 6 
{s,e,a, j,c} 

(4) Strategies cannot connect to other strategies or evidence: 

(n -A m) A [l(n) = s] =f> l(m) 6 {g,a,j,c} 

For this paper, note that in Definition 1 we have excluded the concept of an undeve- 
loped node; consequently our definition of a pattern (Definition 2) excludes the notions 
of UI or UU nodes. Extending both definitions to include these is straightforward. 

Definition 2 (Pattern). A pattern V is a tuple (N, l, t,p, m , c, -a), where ( N , -a) is a 
directed hypergraph 4 in which each hyperedge has a single source and possibly multi- 
ple targets, the structural conditions from Definition 1 hold, and l, t, p, m, and c are 
labeling functions, given as follows: 

2 Annotating an entity as "undeveloped” is part of the main GSN syntax to indicate incomplete- 
ness, i.e., that an entity requires further support. 

3 A safety case argument structure has a single root. 

4 A graph where edges connect multiple vertices. 
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Fig. 1. Abstractions in GSN for patterns specification and our proposed modifications 

(1) 1 and t are as in Definition 1 above 

(2) p is a parameter label on nodes, p : N — *■ Id x T, giving the parameter identifier 
and type. Without loss of generality, we assume that nodes have at most a single 
parameter 

(3) m : (— >) x N — > (N x N) gives the label on the i ,h outgoing connector 5 . Without 
loss of generality, we assume that multiplicity only applies to outgoing connectors. 
If it is (l, h) then multiplicity has the range l..h, where l < h. An optional connector 
has range 0..1. 

(4) c : (— >) — > N x N, gives the “l..h of n” choice range. We give ranges and omit 
the n. 

Fig. 1 illustrates the GSN abstractions for pattern specification formalized in Defini- 
tion 2. We now give some notational conventions and auxiliary definitions that we will 

make use of: 

(a) As shown in Fig. 1 . pattern nodes take parameters, which reference a set of values 
V, partitioned into types, and T ranges over types. We write v :: T, when v is a 
value of type T. 

(b) A pattern node N is a data node, written as data(N), if it has a parameter, i.e., 
N G dom(p) (nodes Gl, SI, G2 and G3 in Fig. 1). Otherwise, a node is boilerplate 
(node S2 in Fig. 1). We will write bp(N) when N is a boilerplate node. For certain 
nodes, e.g., so-called evidence assertions [14], data may not be available until after 
instantiation. Although, strictly speaking, they are data nodes, we consider them to 
be boilerplate here (see Section 5 for an example). 

(c) The links of the hypergraph, A — » B. where A is a single node and B is a set of 
nodes, represent choices. We write A — >■ B when A — » B and BeB. 

(d) The bounds on multiplicity and optionality are represented as ranges. To define 
the labeling functions m and c, we treat — > as a set with members (A, B), where 
A — > B. Then, 

- If c((A, B)) = (l, h) we write A — r L h B (range on choice). 

5 Although siblings are unordered in GSN, it is convenient to assume an ordering. 
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- If m((A, B ), _) = (l, h), we write A ~^ l 2 - h B (range on multiplicity). 

(e) We write sub{V,A) for the sub-pattern of V at A, i.e., the restriction of V to 
N' = {X | A — y* X}, and sub(V, A , B) for the restriction of V to {X \ A — >* 
X and B -fy* X}. Roughly, this is the fragment of V between A and B (including 

A, but excluding B and everything below it). 

(f) Write multi(V, B ) if there exists an A E V such that A —y l - h B and h > 1, that 
is, pattern node B can be repeated in instances of V. We will write multi(B) when 
V is obvious, and often consider multi{G, B), where G is a subgraph of V. 

(g) A path, s, in the pattern is a sequence of connected nodes. If s connects A and B, 
we write this as s : A — »* B. 

(h) Write A < B if for all paths from the root s : R — »* B, we have Aes. 

(i) Write A — > n B when there is a path of length n in the pattern between nodes A and 

B. Then we define A — y must B, when every path from A that is sufficiently long 
must eventually pass through some Be B, i.e., Bn.Vs : A — > n X3B E B .B E s. 

We now introduce a restriction on the combination of multiplicities and boilerplate 
nodes. The intuition is that multiplicities should be resolved by data, and not arbitra- 
rily duplicated: it is only meaningful to repeat those boilerplate nodes associated with 
distinctly instantiated data nodes. 

Definition 3 (Multiplicity Condition). We say that a pattern satisfies the multiplicity 
condition when for all nodes B, if multi (B), and not data(B), then there exists a C 
such that B — >* C, datalC), and for all X such that B — X — y* C, not both 
multi(X) and bp{X). 

In other words, a multiplicity that is followed by boilerplate must eventually be fol- 
lowed by a data node, with no other multiplicity in between. This has two consequences: 
(i) we cannot have multiplicities that do not end in data, and (ii) two multiplicities must 
have intervening data. 

In contrast to concrete argument structures, we allow cyclic structures and multiple 
parents in patterns. However, we need a restriction to rule out ‘inescapable’ loops, so 
that recursion is well-founded. 

Definition 4 (Well-foundedness). We say that an argument pattern is well-founded 
when, for all pattern nodes A, and sets of nodes B, such that A B, if A -A musi B 
then it is not the case that for all B E B, B — y must A. 

We give semantics to patterns in the style of a single-step refinement relation IT] . 
Intuitively, the idea is to define the various ways in which indeterminism can be resolved 
in a pattern. As before (Definition 2), pattern V = ( N , l, t,p, m, c, —f) and we describe 
the components of V which are replaced in V' . 

Definition 5 (Pattern Refinement). For patterns V, V , we say that P Cj P' iff any 
of the following cases hold: 

(1) Instantiate parameters: Ifp(n) = {id, T) and v :: T, then replace node contents, t, 
with t' = t © {n ha t{n)[v / id]}. 

(2) Resolve choices: If A ~^ Lh B, B' C B and l < |B'| < h, then replace A — » B 
with A — Y B for each B E B'. 
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(3) Resolve multiplicities: If A ~^ L - h B then replace the link A — » B with n copies 
( that is, disjoint nodes, with the same connections and labels), where l < n < h. 

(4) Unfold loops: If A — >* B, B —y A, and A < B, then let S be the sub-pattern of 
V at A, subifP , A). We create a copy of S and replace the link from B to A with a 
link from B to the copy of S (i.e., we sequentially compose the two fragments). 

Then, V C V iffV CJ V. 

We will define pattern semantics in terms of refinement to arguments. Formally, how- 
ever, a pattern refines to another pattern, so we need to set up a correspondence between 
concrete patterns and arguments structures. We define this as an embedding from the 
set of argument structures into patterns. 

Definition 6 (Pattern Embedding). An embedding £ of an argument structure into a 
pattern is given as £{(N, l, t , — >)) = (N, l, t,p, m , c, —¥■') where p = 0, the labeling 
functions m and c always return 1..1, and hyperedges have a single target, i.e., for all 
nodes A E N, -V (a) = {— > (a)}. 

We can now define the semantics of a pattern as the set of arguments equivalent to 
the refinements of the pattern. 

Definition 7 (Pattern Semantics). Let V be a pattern, let C and A range over patterns, 
and safety case argument structures, respectively. Then 6 , we give the semantics ofP as 

m={A\VQC,£(A) = C}. 

4 Instantiation 

Now, we formalize the concept of a pattern dataset, define a notion of compliance bet- 
ween data and a pattern, and specify a generic instantiation algorithm. 

4.1 Datasets and Tables 

We use sets of values to instantiate parameters in patterns to create instance arguments. 
Roughly speaking, data can be given as a mapping from the identifiers of data nodes to 
lists of values. However, since a pattern is a graph there can be multiple ways to navigate 
through it (due to recursion and nodes with multiple parents) and, therefore, connect the 
instance nodes. To make clear where an instantiated node should be connected, we need 
to associate each ‘instantiation path’ through the pattern with a join point (or simply 
join), indicating where a “pass” through the pattern begins. A join uniquely indicates 
the location at which an instantiated branch of the argument structure is to be appended. 
In practice, join points can be omitted if the location can be unambiguously determined. 

We adopt a liberal notion of pattern instance and do not require all node parameters to 
be instantiated. Moreover, uninstantiated nodes do not appear in the resulting instance 7 . 

6 Strictly speaking, this should be defined as a set of equivalence classes of arguments, where 
we abstract over node identifiers, but we can safely gloss over that here. 

7 Except for special cases where they have been considered as boilerplate (see item (b) on p. 24). 
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Definition 8 (Pattern Dataset). Given a pattern, V, define a P-dataset as a partial 
function r : ( D x V) x D — *■ (IN* — *■ V), where D is the set of data nodes in V, V 
is the set of values, and IN* is the set of indices. We write v E r ’ c r when for some i, 
T(r,c)(i) = v, and require that values be well-typed, i.e., if v E r,c t and p(c) = (id,T) 
then v :: T. 

Data will typically be represented in tabular form where we label columns by data 
nodes, D, and rows by D x V pairs, i.e., joins. Entries in the table are represented 
as indexed lists of values. The order in which a dataset is tabulated does not actually 
provide any additional information, but in order to be processed by the instantiation 
algorithm, must be consistent with the pattern, in the following sense: the order of 
columns must respect node order 8 <, i.e., if A < B then the corresponding columns 
are in that order; and for each row (D, v ), we require that v appears in column D in a 
preceding row. In the following, we will assume that a consistent order has been chosen 
for a dataset, and refer to it as a P-table (see Table 1 for an example). 

Definition 9 (Data Compliance). For pattern V and V -table r, we say that the table 
complies with the pattern, tNP, if the following two conditions hold: 

(i) t meets the cardinality constraints ofV, i.e., Vc.l < |r((_,_),c)| < h, where 
{l, h) = m(i, d), where c' — d c. 

(ii) t is upwards-closed, i.e., for each r labeled ( D , v) and column c, if v E r ’ c r and 
c < d < D, then there exists v' such that v' E r ’ c r. 

Note that the ordering used in upwards-closure is with respect to the pattern and not the 
column order. The intuition behind upwards closure is that, in line with our notion of 
partial instantiation and although not all nodes need be instantiated, we do require that 
parameters can be instantiated in order from the root. A row, therefore, consists of the 
data that instantiates an upward-closed fragment of the pattern, following the paths of 
the fragment up until the join (see Fig. 4 for an example). 

4.2 Algorithm 

Fig. 2 specifies instantiate ^ , r), our generic algorithm for pattern instantiation. We 
write new(D.v), to create a new instance node, given by instantiating data node D 
with value v. When a boilerplate node B is instantiated, then we reference its instance 
simply as B. Fet T be the set of argument structure fragments. To connect an instance 
node D.v to a fragment f E T , we use a function connect(D.v, /), which sequentially 
composes / with the current instance fragment at node D.v. 

To instantiate a pattern V, given its P-table r, we process each row to create a row 
instance fragment, which is effectively the assignment of parameter values in the table 
to the corresponding data nodes in the pattern. We construct the row instance based 
on the ordering of the data nodes in the columns. For each value we add not just the 
instantiation of the appropriate data node, but also any boilerplate between that node and 
the preceding data node. We give a row instance as RI E iVxNxf*, where N, N, and 
IN* are the sets of pattern nodes, instance nodes and natural number indices respectively. 


See item (h) on p. 25. 
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1 Instantiate (P: Pattern, t: V -table ) 

2 begin 

3 foreach row r £ table r do 

4 initialize row instance RI 4— 0 

5 if row label — (root,v) then 

6 I create instance node j 4— new(root.v) and assign pattern node current 4— root 

7 I update row instance RI 4— RI U (current, j, []) 

8 else if row label = (C, v ) then 

9 create join instance node j 4— new( C.v) and assign current 4— C 


10 

11 

12 

13 

14 

15 

16 

17 

18 

19 

20 
21 
22 
23 


foreach column E £ table t not including root do 
assign pattern node N 4— current 
foreach (v, index i) £ table r(r, E) do 

assign fragment / 4— boilerplate B £ sub(V, current, E) such that multi( B) V (B,B, []) ^ RI 
if E is first column in row r with data then assign instance node n 4— j 
else find parent node n with index k such that 3(N,n, k) £ RI 
connect (n, /) 

foreach boilerplate B £ f do update row instance RI 4— RI U (B,B,i) 

if 3P £ sub(V, current, E) | multi( P) then assign pattern node N 4— parent(P) 

assign pattern node M 4— parent(E) 

assign instance node p 4— instance node m £ / such that m = M.u 
connect (p, E.i;) 

update row instance RI 4— RI U (E, E.?;,i) 
assign current 4— E 


Fig. 2. Generic algorithm for pattern instantiation 


Multiplicities, especially, require careful consideration: multiple values in the P-table 
lead to multiple instances of a data node, but we only repeat those boilerplate nodes 
which appear after a multiplicity (see Fig. 4 for an example). We use instance indices to 
connect nodes to the correct parent when there are such multiples. At any point in the 
algorithm we identify the “current node” as current, and the pattern root as root. 

We now state, without proof, the correctness property of the instantiation algorithm. 

Correctness: If V is a well-founded pattern that satisfies the multiplicity condition, and 
r 1= V, then instantiate^ , r) £ \P\. A consequence is that the algorithm produces 
well-formed instances. 

5 Illustrative Example 

To illustrate pattern instantiation, we use the requirements breakdown pattern (Fig. 3), 
which we have derived from our ongoing experience with safety case development for 
an unmanned aircraft system [2], [4], [6]. It also extends our previous work 9 on algorith- 
mically deriving argument structure fragments from requirements/hazards tables [3]. 

The requirements breakdown pattern (Fig. 3) provides a framework to abstractly 
represent the argument implicit in a requirements table 10 . Specifically, it shows how 
the claims entailed by requirements can be hierarchically developed and linked to the 
supporting evidence produced from the specified verification methods. Due to space 
limitations, we do not provide a complete pattern specification. 

9 In fact, a P-table similar to Table 1 can be extracted from the tables in [3]. 

10 See [3] for an example of a requirements table. 
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Lower-level requirement 
{rl :: requirement} holds 


9 



Fig. 3. Requirements breakdown pattern, abstracting the structure of the argument implicit in a 
requirements table 


Table 1. Example of a populated P-table to instantiate the requirements breakdown pattern 


Parameter Type 

Requirement 

Lower-level 

requirement 

Allocated 

Requirement 

Source 

Requirement 

Allocation 

Verification 

Method 

Verification 

Allocation 

— .Data node 
Join 

G1 

G2 

G3 

Cl 

C2 

S3 

El 


Rl 

R1.1, Rl .2 

AR1 

s 

A 

VM11, VM12 

VA11 , VA12 

(S3, VM12) 







VA22 

(G2, R1.1) 






VM1.11, VM1.12 

VA1.11, VA1.12 

(G2, R1.2) 


R1.2.1, Rl .2.2 

AR1.2 





(G2, R1.2.1) 






VM1.2.1 

VA1.2.1 

(G3.AR1.2) 



AR1.21 



VM1.2 

VA1.2 





Row instance fragment (row 1) 
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Fig. 4. Application of the generic pattern instantiation procedure (Algorithm 2): Concrete instance 
of the requirements breakdown pattern (Fig. 3) using the values from the "P-table (Table 1), 
highlighting row instance fragments, join points and repetition of boilerplate nodes 
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In brief, the claim in the root goal (Gl) of the pattern is that a safety/system re- 
quirement, which is usually made in the contexts of some source (Cl), or system, i.e., 
requirement allocation (C2), holds. A choice of three strategies is available to develop 
Gl: hierarchical decomposition (SI, S2) and appeal to one or more verification me- 
thods (S3). The sub-claims (G2, G3) resulting from applying hierarchical decomposi- 
tion are semantically similar to the root claim that they refine. Consequently, we can 
apply the same strategies to develop them further. Eventually, we support all claims by 
verification evidence (El). The evidence is preceded by an evidence assertion (G4), i.e., 
a minimal proposition directly concerning the source data of the evidence [14]. 

Table 1 shows a populated "P-table for the requirements breakdown pattern with the 
columns, labeled by the pattern data nodes, containing example data entries entered 
corresponding to the root node and the join points. We have listed the data node 
parameter type for clarification purposes and it is not formally part of the data model. 

Fig. 4 shows an instance of the pattern derived by applying our generic pattern 
instantiation procedure (Algorithm 2) and using the "P-table (Table 1). It highlights 
the repetition of boilerplate nodes 11 after multiplicity, and illustrates how a join point 
connects two row instance fragments. 

6 Conclusion 

We have presented the foundational steps towards, we believe, a rich theory of safety 
case patterns that will enable more sophistication in their usage than is currently avai- 
lable, e.g., automated instantiation, composition, and transformation-based manipula- 
tion. The main benefit of our work from a practitioner’s perspective, we anticipate, 
is a reduction in the effort involved in safety case creation/management due to the 
raised level of abstraction at which arguments can be formulated, together with im- 
proved assurance. Specifically, given the assurance afforded by automated instantiation 
that a pattern instance is well-formed and meets its specification, practitioners, i.e., 
safety engineers who create safety arguments, and certification/qualification authorities 
who evaluate them, can divert efforts to domain-specific issues, e.g., selecting the ap- 
propriate patterns for assurance, evaluating a smaller, abstract argument structure for 
fallacies/deficits instead of its larger concrete instantiation, determining the evidence 
required to support the claims made, etc. 

However, more can be done: as mentioned earlier, the formal definitions and the al- 
gorithm can be extended to include the notions of undeveloped, UI and UU. One design 
choice in the algorithm was to instantiate only those nodes for which parameters have 
values in the data table. An alternative choice could be to use the whole pattern so that 
those data nodes that do not take values in the table are also reproduced in the instance 
but left as UI or UU, as appropriate. The relationship between modular abstractions, 
hierarchies [7], and patterns is, as yet, unclear although there are a few examples of 
applying patterns within a modular organization [9]. The goal of formalization, here, 
would be to raise the level of abstraction and to increase automation. We use a notion 
of sequential composition of patterns. We have also defined a notion of parallel compo- 
sition (not given in this paper) to create patterns, such as for requirements breakdown 

11 Recall that we consider evidence assertion nodes as boilerplate (see item (b) on p. 24). 
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(Fig. 3), from simpler patterns. Future work will involve, in part, extending the formal 
basis given in this paper to the topics mentioned above. 

We have already implemented the GSN abstractions and our notational extensions for 
patterns in our toolset, AdvoCATE [5]; we plan to extend the tool with the algorithm 
described here. Clarifying concepts such as patterns and the data for their instantiation 
will be necessary to support tool interoperability, which is one of the goals [13] of 
emerging safety/assurance case standards. 
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